Today most merchants, whether brick and mortar or Internet, accept electronic payments (e.g., credit cards, debit cards, gift cards) as tender for transactions. Electronic payments may also be accepted by vending machines, kiosks, automated tellers or other systems where a human is not needed to conduct the transaction or process an electronic payment as tender for the transaction.
FIG. 1 illustrates an example architecture used to process electronic payments for merchant transactions. The architecture includes a merchant system 110, a payment handler 120, a communication network 130, and a payment processing system 140. The merchant system 110 may be a hardware system (e.g., electronic cash register (ECR), point of sale (POS)) or may be a software system (e.g., POS). The merchant system 110 may track items purchased and generate an invoice/sales receipt based on the cost of those items purchased and any taxes and/or discounts applied. The merchant system 110 may include an interface for gathering data about the transactions. The interface may include, but is not limited to, a scanner to scan codes associated with items (e.g., UPC codes), a keyboard to enter data associated with items, or a touch screen to select items. The merchant system 110 may be tied to other systems (e.g., inventory system, management system). The merchant system 110 may also include an interface to gather electronic payment information (e.g., card number). The interface may include, but is not limited to, a card reader (swiper), a scanner, a keyboard, or a touch screen.
The payment handler 120 may process the electronic payment information so that it can be communicated to the payment processing center 140 along with the transaction data (payment amount). The payment handler 120 may be separate from the merchant system 110, interfaced to the merchant system 110 or integrated into the merchant system 110. The payment handler 120 may receive the transaction data (payment amount) from the merchant system 110 or the payment amount may be entered into payment handler 120. The payment handler 120 may receive the electronic payment information from the merchant system 110, from an electronic payment information device (not illustrated) connected to the payment handler 120, or the electronic payment information may be entered into payment handler 120. The payment handler 120 may include an interface to gather electronic payment information. The interface may include, but is not limited to, a card reader (swiper), a scanner, a keyboard, or a touch screen. The payment handler 120 may be configured to include information related to a merchant-payment processor relationship (merchant account), including identification information for the merchant in the payment processing system 140, and the configuration details may be utilized to communicate with the payment processing center 140.
The communication network 130 provides communications between the payment handler 120 and the payment processing system 140. The communication network 130 may be a phone network, the Internet and/or a wireless network.
The payment processing system 140 receives and processes electronic payment transactions from the payment handler 120. The electronic payment transactions received may include information related to the transaction (e.g., payment amount), information related to the electronic payment used (e.g., credit card number), and information related to the merchant (e.g., merchant identifying information). The payment processing system 140 may determine if the transaction received is authorized for the merchant (e.g., does merchant accept that type of credit card) and if the electronic payment can be processed (e.g., is transaction amount within card limit of the purchaser). Once the transaction is approved, the payment processing system 140 may process payment from the card company to the merchant based on identification of the merchant included in the electronic payment transaction.
FIGS. 2A-2C illustrate several example merchant system-payment handler architectures. FIG. 2A illustrates an architecture where the merchant system 110 and the payment handler 120 are separate devices that are not interfaced together or communicating directly with one another. The merchant system 110 does not communicate merchant transaction data (e.g., payment amount) to the payment handler 120 so the transaction data (payment amount) needs to be entered (manually) into the payment handler 120. Additionally, cross referencing may be required between the merchant transactions processed in the merchant system 110 and the electronic payment transactions processed in the payment handler 120. The payment handler 120 may include an electronic payment interface (e.g., card reader, scanner, keyboard) for accepting data related to the consumer and their electronic payment (e.g., credit card number). The payment handler 120 may include a user interface (e.g., keyboard) for entering the merchant transaction data. The payment handler 120 is basically a data terminal used to enter merchant transaction data and electronic payment transaction data and communicate the transaction to the payment processing system 140.
FIG. 2B illustrates an architecture where the merchant system 110 and the payment handler 120 are separate devices that are interfaced together and communicate therebetween. The merchant system 110 provides the merchant transaction data to the payment handler 120. The merchant system 110 may include an electronic payment interface (e.g., card reader, scanner, keyboard) for accepting data related to the consumer and their electronic payment (e.g., credit card number) and may provide the electronic payment information to the payment handler 120. The payment handler 120 may process the merchant transaction information and the electronic payment information and forward to the payment processing system 140.
FIG. 2C illustrates an architecture where the merchant system 110 and the payment handler 120 are integrated into a single device. The payment handler 120 may be software, hardware or firmware within the merchant system 110. The payment handler 120 may receive the merchant transaction data from the merchant system 110. The merchant system 110 may include an electronic payment interface for accepting data related to the consumer and their electronic payment. The electronic payment data may be provided to the payment handler 120. The payment handler 120 may process the merchant transaction data and the electronic payment information and forward to the payment processing system 140.
When a merchant and a payment processor execute an agreement for the payment processor to handle electronic payment transactions for the merchant (establish a merchant account) the payment processor creates a profile for the merchant (processor side merchant profile) that identifies the merchant and defines parameters associated with their account. The processor side merchant profile may define the types of transactions authorized and include various identifications (e.g., merchant ID, payment processor ID, merchant account ID). The processor side merchant profile may be stored in the payment processing system 140. The payment processing system 140 may utilize the processor side merchant profile to identify incoming transactions with the merchant, validate the transactions, and process the transactions according to the merchant account. The payment processing system 140 may require the incoming transactions to be a certain format and contain certain data from the processor side merchant profile in order to identify, validate and process the transactions.
Regardless of the type of payment handler 120 used, in order for the electronic transactions to be processed the payment handler 120 needs to be configured in order to communicate with the payment processing system 140. The configuration of the payment handler 120 requires that a profile for the merchant (client side merchant profile) be programmed therein. The client side merchant profile may be similar to the processor side merchant profile and the two merchant profiles may contain at least a portion of the same data. The client side merchant profile may be substantially the same as the processor side merchant profile and the two merchant profiles may contain substantially the same data. The payment handler 120 may transmit various items from the client side merchant profile to the payment processing system 140 as part of electronic payment transaction.
The configuration of the payment handler 120 requires an understanding of the payment handler 120 and how to program it. The configuration of the payment handler 120 requires knowledge of the merchant account (e.g., allowable transactions), and the type and format of data that the payment processing center 140 requires. The configuration of the payment handler 120 requires coordination with the payment processor (payment processing system 140). The installation and configuration of the payment handler 120 is usually too complicated for the typical merchant. Accordingly, vendors are typically utilized to install and configure the payment handlers 120 for merchants. The vendors may coordinate with the payment processor in order gather the information necessary to configure the payment handler 120 (e.g., program the client side merchant profile therein). The delivery, installation, configuration and validation of the payment handler 120 is a significant cost factor in deploying a new merchant account.
Furthermore, if the merchant profile becomes corrupt the payment handler 120 may need to be reconfigured. Additionally, if attributes related to the merchant account change (e.g., allow additional transactions) the payment handler 120 may need to be reconfigured. Moreover, if the payment processing system 140 is modified (e.g., data required or format of data from payment handler 120 changes, payment processing center contact information (e.g., IP address) changes) the payment handler 120 may need to be reconfigured. The reconfiguration of the payment handler 120 may require the vendor to return for reconfiguration thereof, the payment handler 120 to be returned for reconfiguration, or replaced with a unit that has been reconfigured. Alternatively, the payment processor or the vendor may attempt to talk the merchant through the reconfiguration or may attempt to reconfigure the payment handler 120 remotely using a communication network. Regardless of the form of reconfiguration utilized, it may result in delays and additional costs.
Merchants, vendors or other parties that know how to configure a payment handler 120 can configure the devices to operate with other payment processing systems 140 and/or for other merchants. They may do this by programming a different merchant profile into the payment handler 120. This enables the same device to be reused by the same merchant for different merchant agreements or to be used by different merchants. The reprogramming of the payment handlers 120 creates an aftermarket for the devices that is out of the control of the payment processors or equipment manufactures. The aftermarket reduces the amount of payment handlers 120 required for new merchant accounts and thus reduces the profits the payment processors or equipment manufactures can make by charging for the devices as part of the merchant contract.
What is needed is a way to simplify and/or eliminate the configuration of the payment handlers 120 during initial set-up and for reconfigurations required thereafter. What is also needed is a way to reduce or eliminate the reprogramming of payment handlers 120 so that the payment handlers 120 are controlled by the payment processors or the equipment manufacturer.